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CHAPTER II 



Preliminary Classification: 
Proposed Class: 
Subclass: 

NOTE: "All applicants are requested to include a preliminary classification on newly fifed patent 

applications. The preliminary classification, preferably class and subclass designations, should be 
identified in the upper right-hand comer of the fetter of transmittal accompanying the application 
papers, for example 'Proposed Class 2, subclass 129. ' " M.P.E.P., § 601, 7th ed. 
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APPUCANT(S) 
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Box PCT 

Assistant Commissioner for Patents 
Washington D.C. 20231 

ATTENTION: EO/US 





CERTIFICATION UNDER 37 C.F.R. § 1.10* 
(Express Mali label number Is mandatory.) 
(Express Mail certification is optional.) 

I hereby certify that this Transmittal Letter and the papers indicated as being transmitted therewith is being 

deposited with the United States Postal Service on this date June l y 2000 ( j n an envelope as 

-Express Mail Post Office to Addressee" Mailing Label Number EI.336865470I1S , addressed to the: 

Assistant Commissioner for Patents, Washington, D.C, 20231, 



Carm Marsh 




Signature of person mailing paper 



WARNING: Certificate of mailing (first class) or facsimile transmission procedures of 37 C.F.R. § 1.8 cannot be 
used to obtain a date of mailing or transmission for this correspondence. 

WARNING: Each paper or fee fifed by "Express Mail" must have the number of the "Express Mail" mailing label 
placed thereon prior to mailing, 37 C.F.R § 1.10(b). 

"Since the filing of (x>rrespondence under § 1. 10 without the Express Mail mailing label thereon 
is an oversight that can be avoided by the exercise of reasonable care, requests for waiver of this 
requirement win not be granted on petition. "Notice of Oct 24, 1996, 60 Fed. Reg. 56,439, at 66,442. 
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NOTE- To avoid abandonment of the application, the applicant shall furnish to the USPTO. not later than 20 
months from the priority date: (1) a copy of the international application, unless it has been P^sfy 
communicated by the International Bureau or unless it was originally filed in the USPTO; and (2) the 
basic national fee (see 37 C.F.R. § 1.492(a)). The 30-month time limit may not be extended. 37 C.F.H. 
§ 1.495. 

WARNING: Where the items are those which can be submitted to complete the entry of the international 
application into the national phase are subsequent to 30 months from the pnonty date the 
application is still considered to be in the international state and if mailing procedures are utilized 
to obtain a date the express mall procedure of 37 C.F.R. § 1.10 must be used (since MflMml 
application papers are not covered by an ordinary certificate of mailing— See 37 C.F.H. § 1.8. 
NOTE: Documents and fees must be clearly identified as a submission to enter the national ^ate under 35 
U.S.C. § 371 otherwise the submission will be considered as being made under 35 U.b.u $ 7 7 7. j/ 
C.F.R. § 1.494(f). 

Applicant herewith submits to the United States Elected Office (EO/US) the following 
items under 35 U.S.C. § 371: 

a. D This express request to immediately begin national examination procedures 

(35 U.S.C. § 371(f)). 

b. D The U.S. National Fee (35 U.S.C. § 371 (c)(1)) and other fees (37 C.F.R. § 1 .492) 

as indicated below: 
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CLAIMS 
FEE 



BASIC FEE** 



(1) FOR 



TOTAL 
CLAIMS 



4 8 



INDEPENDENT 
CLAIMS 

13 



(2) NUMBER 
FILED 



47 



-20 = 



13 



3 = 



(3) NUMBER 
EXTRA 



27 



10 



(4) RATE 



x $18.00 = 



x $78.00- 



(5) CALCULA- 
TIONS 



$ 486.00 



MULTIPLE DEPENDENT CUUM{S) (if applicable) 



+ $260.00 



780.00 



□ 



□ 



□ U.S. PTO WAS INTERNATIONAL PRELIMINARY EXAMINATION 

AUTHORITY . . f 

Where an International preliminary examination fee as set forth 
in § 1.482 has been paid on the international application to the 

U.S. PTO: . 

and the international preliminary examination report 
states that the criteria of novelty, inventive step (non- 
obviousness) and industrial activity, as defined in PCT 
Article 33(1) to (4) have been satisfied for all the 
claims presented in the application entering the 

national stage (37 C.F.R. § 1.492(a)(4)) „ ^ $96.00 

and the above requirements are not met (37 C.F.H. 

§ 1.492(a)(1)) S 670 ' 00 

U.S. PTO WAS NOT INTERNATIONAL PRELIMINARY 
EXAMINATION AUTHORITY 

Where no international preliminary examination fee as set forth 
in § 1.482 has been paid to the U.S. PTO, and payment of an 
international search fee as set forth in § 1.445(a)(2) to the U.S. 

PTO' 

* has been paid (37 C.F.R. § 1.492(a)(2)) W90 -°0 

has not been paid (37 C.F.R. § 1.492(a)(3)) $970.00 

where a search report on the international application 
has been prepared by the European Patent Office or 
the Japanese Patent Office (37 C.F.R. 
§ 1.492(a)(5)) $840 ' 00 



SMALL 
ENTITY 



TOTAL 



□ 
□ 
® 



840.00 



Total of above Calculations = 2 , 106.00 



Reduction by 1/2 for filing by small entity, if applicable. Affidavit 
must be filed also, (note 37 C.F.R. § 1.9. 1-27, 1.28) 



Subtotal 



Total National Fee $ ^ ^ ^ ^ Q0 



Fee for recording the enclosed assignment doc ^ n ^'^^ NT 
C.F.R. § 1.21(h)). (See Item 13 below). See attached "ASSIGNMENT 



COVER SHEET". 
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*See attached Preliminary Amendment Reducing the Number of Claims. 

i. E A check in the amount of $2 ' 106 - 00 to cover the above fees is enclosed. 

H. □ Please charge Account No in the amount of $ 

A duplicate copy of this sheet is enclosed. 

-WARNING' To avoid abandonment of the application the applicant shall furnish to the United states Patent 
and Trademark Office not later than the expiration of 30 months from the prionty date: (2) 
the basic national fee (see § 1.492(a)). The 30-month time limit may not be extended. m 37 C.F.R. 
§ 1.495(b). 

WARNING- If the translation of the international application and/or the oath or declaration have not been 
' submitted by the applicant within thirty (30) months from the priority date, such requirements may 
bemetwithinaUrr^periodsetbytheOffice.37C.F.R.§ 1 .495f>)(2). The payment of the surcharge 
set forth in § 1.492(e) is required as a condition for accepting the oath or declaration later than 
thirty (30) months after the priority date. The payment of the processing fee set forth in § 1.492® 
is required for acceptance of an English translation later than thirty (30) months after the pnonty 
date Failure to comply with these requirements will result in abandonment of the application. The 
provisions of § 1.136 apply to the period which is set Notice of Jan. 3, 1993, 1147 O.G. 29 to 
40. 

3. □ A copy of the International application as filed (35 U.S.C. § 371(c)(2)): 
NOTE- Section 1.495 (b) was amended to require that the basic national fee and a copy of the international 
' application must be filed with the Office by 30 months from the priority date to *™ d *^^ n ™ n 
nrm International Bureau normally provides the copy of the international application to the Office in 
accordance with PCT Article 20. At the same time, the International Bureau notifies applicant of the 
communication to the Office. In accordance with PCT Rule 47.1. that notice shall be accepted by aU 
designated offices as conclusive evidence that the communication has duly taken place. Thus, if Vie 
applicant desires to enter the national stage, the applicant normally need 

Ztice from the International Bureau has been received and then pay the ^/^onalhe by 30 mcrths 
Zm the priority date.* Notice of Jan. 7, 1993, 1147 O.G. 29 to 40, at 35-36. See item 14c below. 

a. □ is transmitted herewith. 

b. □ is not required, as the application was filed with the United States 
Receiving Office. 

c. □ has been transmitted 

i. □ by the International Bureau. 

Date of mailing of the application (from form PCT/1B/308): . 



iL □ by applicant on 



Date 

4 □ A translation of the International application into the English language 
(35 U.S.C. § 371(c)(2)): 

a. □ is transmitted herewith. 

b. □ is not required as the application was filed In English. 

c □ was previously transmitted by applicant on 

Date 

d. □ will follow. 
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5. Q Amendments to the claims of the International application under PCT Article 19 
(35 U.S.C. § 371(c)(3)): 

NOTE- The Notice of January 7, 1993 points out that 37 G.F. A § 1.495(a) was amended to clarify the existing 
and continuing practice that PCT Article 19 amendments must he submitted by 30 months from the 
priority date and this deadline may not be extended. The Notice further advises that: -The failure to 
do so will not result in loss of the subject matter of the PCT Article 19 amendments. Applicant may 
submit that subject matter in a preliminary amendment filed under section 1. 121. In many cases, filing 
an amendment under section 1.121 is preferable since grammatical or idiomatic errors may be 
corrected.* 1147 O.G. 29-40, at 36. 

a. □ are transmitted herewith. 

b. □ have been transmitted 

i. □ by the International Bureau. 
Date of mailing of the amendment (from form PCT/1 B/308): — 

ii. □ by applicant on (date) _ 

Date 

c. □ have not been transmitted as 

i. □ applicant chose not to make amendments under PCT Article 19. 
Date of mailing of Search Report (from form PCT/ISA/210.): 

ii. □ the time limit for the submission of amendments has not yet expired. 
The amendments or a statement that amendments have not been made 
will be transmitted before the expiration of the time limit under 
PCT Rule 46.1. 

6. □ A translation of the amendments to the claims under PCT Article 19 
(38 U.S.C. § 371(c)(3)): 

a. □ is transmitted herewith. 

b. □ is not required as the amendments were made in the English language. 

c. □ has not been transmitted for reasons indicated at point 5(c) above. 

7. S A copy of the international examination report (PCT/IPEA/409) 
Be is transmitted herewith. 

□ is not required as the application was filed with the United States Receiv- 
ing Office. 

8. □ Annex(es) to the international preliminary examination report 

a. □ is/are transmitted herewith. 

b. □ is/are not required as the application was filed with the United States 
Receiving Office. 

9. □ A translation of the annexes to the international preliminary examination report 

a. □ is transmitted herewith. 

b. □ is not required as the annexes are in the English language. 
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10. Q An oath or declaration of the inventor (35 U.S.C. § 371(c)(4)) complying with 

35 U.S.C. § 115 

a. □ was previously submitted by applicant on 

Date 

b. □ is submitted herewith, and such oath or declaration 

i. □ is attached to the application. 

ii. □ identifies the application and any amendments under PCT Article 
19 that were transmitted as stated in points 3(b) or 3(c) and 5(b); and 
states that they were reviewed by the inventor as required by 

37 C.F.R. § 1.70. 

iii. K will follow. 

II. Other document(s) or information included: 

11. □ An International Search Report (PCT/iSA/210) or Declaration under 

PCT Article 17(2)(a): 

a. □ is transmitted herewith. 

b. □ has been transmitted by the International Bureau. 
Date of mailing (from form PCT/IB/308): 

c. □ is not required, as the application was searched by the United States 
International Searching Authority. 

d. □ will be transmitted promptly upon request. 

e. □ has been submitted by applicant on 

Date 

12. □ An Information Disclosure Statement under 37 C.F.R. §§ 1.97 and 1.98: 

a. □ is transmitted herewith. 

Also transmitted herewith is/are: 

□ Form PTO-1449 (PTO/SB/08A and 08B). 

□ Copies of citations listed. 

b. □ will be transmitted within THREE MONTHS of the date of submission 
of requirements under 35 U.S.C. § 371(c). 

c. □ was previously submitted by applicant on 

Date 

13. □ An assignment document is transmitted herewith for recording. 

A separate □ "COVER SHEET FOR ASSIGNMENT (DOCUMENT) ACCOMPA- 
NYING NEW PATENT APPLICATION" or □ FORM PTO 1595 is also attached. 
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14. t£] Additional documents: 

a. □ Copy of request (PCT/RO/101) 

b. Ei International Publication No. WO 99/2887 .2 

i. 0 Specification, claims and drawing 

ii. □ Front page only 

c. GO Preliminary amendment (37 C.F.R. § 1.121) 

d. □ Other 



15. QQ The above checked items are being transmitted 

a. 13 before 30 months from any claimed priority date. 

b. □ after 30 months. 

16. □ Certain requirements under 35 U.S.C. § 371 were previously submitted by 

applicant on , namely: 



AUTHORIZATION TO CHARGE ADDITIONAL FEES 

WARNING: Accurately count claims, especially multiple dependant claims, to avoid unexpected high charges 
if extra claims are authorized. 

NOTE' "A written request may be submitted in an application that is an authorization to treat any concurrent 
or future reply, requiring a petition foran extension of time under this paragraph for its timely submission, 
as incorporating a petition for extension of time for the appropriate length of time. An ^thonzation to 
charge all required fees, fees under §1.17, or all required extension of time fees will be treated as 
a constructive petition for an extension of time in any concurrent or future reply requtnng a petition 
for an extension of time under this paragraph for its timely submission. Submission of the fee set forth 
in § 1 17(a) will also be treated as a constructive petition for an extension of time in any concurrent 
reply requiring a petition for an extension of time under this paragraph for its timely submission. 37 
C.F.R § 1.136(a)0). 

NOTE' -Amounts of twenty-five dollars or less wilt not be returned unless specifically requested within a 
reasonable time, nor will the payer be notified of such amounts; amounts over twenty-five dollars may 
be returned by check or, if requested, by credit to a deposit account" 37 C.F.R. § 1.26(a). 

GD The Commissioner is hereby authorized to charge the following additional 
fees that may be required by this paper and during the entire pendency of 

this application to Account No 16-1350 — 

Si 37 C.F.R. § 1.492(a)(1), (2), (3), and (4) (filing fees) 
WARNING- Because failure to pay the national fee within 30 months without extension (37 C.F.R. § 1.495(b)(2)) 
results in abandonment of the application, it would be best to always check the above box. 
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B 37 CF.R. § 1.492(b), (c) and (d) (presentation of extra claims) 
NOTE* Because additional fees forexcess or multiple dependent claims not paid on filing or on later presentation 
must only be paid or these claims cancelled by amendment prior to the expiration of trie ttme penod 
set for response by the PTO in any notice of fee deficiency (37 CF.R. § 1.492(d)), it might be best 
not to authorize the PTO to charge additional claim fees, except possible when dealing with amendments 
after final action. 

IS 37 CF.R. § 1.17 (application processing fees) 

□ 37 CF.R. § 1.17(a)(1H5) (extension fees pursuant to § 1.136(a). 

□ 37 CF.R. §1.18 (issue fee at or before mailing of Notice of Allowance, 
pursuant to 37 CF.R. § 1.311(b)) 

NOTE' Where an authorization to charge the issue fee to a deposit account has been filed before the mailing 
of a Notice of Allowance, the issue fee will be automatically charged to the deposit account at the time 
of mailing the notice of allowance. 37 CF.R. § 1.311(b). 
NOTE- 37 C F.R § 1.28(b) requires "Notification of any change in loss of entitlement to small entity status must 
be filed in the application. . . prior to paying, or at the time of paying . . .issue >fee. "From the wording 
of37CFR § 1 28(b): (a) notification of change of status must be made even if the fee is paid as other 
than a small entity" and (b) no notification is required if the change is to another small entity. 

H 37 CF.R. § 1.492(e) and (f) (surcharge fees for filing the declaration 
and/or filing an English translation of an International Application later 
than 30 months after the piiority^ate). 

PLEASE SEND AIL CORRESPONDENCE TO: 




Reg. No.: 24,622 

Tel. No.: ( 203 ) 259-1800 

Customer No.: 



SI&tiATURE OF PRA 

CI arence A. Green 




{type or print name of practitioner) 

PERHAN & GREEN, LLP 

P.O. Address 

425 Post Road, Fairfield, Connecticut 06430, USA 
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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Express Mail No.: EL336865470US 

In re Application of: WODEHOUSE et al. 

INTERNATIONAL APPLICATION NO.: PCT/GB98/03537 

INTERNATIONAL FILING DATE: 26 November 1998 

U.S. SERIAL NUMBER: 

FILING DATE: Herewith 

TITLE: METHOD AND APPARATUS FOR MONEY TRANSFERS 
ATTORNEY DOCKET NO. : 228-009468-US(PAR) 



Box PCT 

The Commissioner of Patents and Trademarks 
Washington, D.C. 20231 



PRETXMINARY AMENDMENT 

Dear Sir: 

Please amend the above-identified, enclosed patent application as follows: 
TN THE CLAIMS: 

Please amend Claims 5, 8, 9, 13, 15, 17, 18, 19, 20, 26, 29, 30, 31, 34, 42, 43, 46 
and 47 as shown below. 

Claim 5, line 1, delete "2, 3 or 4,". 

Claim 8, line 1, delete "any preceding claim" and insert -claim 1-. 



Claim 9, line 1, delete "any preceding claim" and insert 



—claim 1— 



2 

Claim 13, line 1, delete "or 12". 

Claim 15, line 1, delete "12, 13, 14 or 15,". 

Claim 17, line 1, delete "or 16". 

Claim 18, line 1, delete "16 or 17,". 

Claim 19, line 1, delete "16 or 17,". 

Claim 20, line 1, delete "any preceding claim" and insert -claim 1--. 
Claim 26, line 1, delete "22, 23, 24, or 25,". 

Claim 29, line 1, delete "any of claims 21 to 28" and insert --claim 21-. 
Claim 30, line 1, delete "any of claims 21 to 31" and insert -claim 21-. 
Claim 31, line 1, delete "32" and insert -30-. 
Claim 34, line 1, delete "or 33". 
Claim 42, line 1, delete "or 41". 

Claim 43, line 1, delete "any of claims 47 to 49" and insert -claim 40--. 
Claim 46, line 1, delete "or 45". 
Claim 47, line 1, delete "45 or 46,". 



3 



PLEASE CANCEL CLAIM 48. 



REMARKS 



Please enter this preliminary amendment prior to calculation of the fees. 



Respectfiuly submitted, 





Clareriee A. Green, Reg. No. 24,622 
PERMAN & GREEN, LLP 
425 Post Road 
Fairfield, CT 06430 
(203) 259-1800 




Date 



W m : nso'd pct/pto 01 m 2000, 

METHOD AND APPARATUS FOR MONEY TRANSFERS 



This invention relates to method and apparatus for facilitating money transfer. 
The invention is particularly suitable for inter-country money transfers, but it is not 
5 limited exclusively to this. 

Money transfer services are offered by a number of organisations, for example 
banks, the Moneygram organisation, and the Western Union organisation. A transferee 
wishing to transfer money is able to visit a local authorised agent and arrange for 
money to be made available for collection by a transferee at another authorised agent or 
10 bank, for example, in a different country. 

In developing the present invention, it has been appreciated that conventional 
techniques suffer from certain problems: 

(i) Identification of the transferee. Normally, a transferee will be required to 
present proof of identification, for example, a passport or driving licence, before being 

15 permitted to collect the funds. However, there are a large number of countries in 
which many people do not holds passports or other officially recognisable proof of 
identification. In such cases, money transfer may be limited to postal transfers. 
Western Union offers a code-word facility by which a transferor can provide a code 
word with the initial transfer instructions. The transferee is required to present a 

20 matching code word instead of presenting proof of identification. 

(ii) Security. Particularly when a code word is used, there is a risk of the 
transferee, or other parties involved in the money transfer process, committing fraud. 
It will be appreciated that, especially in certain countries, fraud and corruption may be 
commonplace, and difficult to control from outside the country. In general, the 

25 transferee, and the bank staff in the country of the transferor and the transferee, all 
have access to the code word and sufficient other information to collect the funds and 
to complete the transaction (since no proof of identity is required). Such fraud is very 
difficult to detect and to prevent. 

(iii) Accuracy of information. Often, information is passed orally within a transfer 
30 organisation by telephone. This can lead to inaccuracies in the information, 



particularly when unfamiliar pronunciation is involved, or if two people are not fully 
conversant in the same language. For example, if a the name of the transferee is 
misspelt, then it may be impossible for the correct transferee to collect the funds even 
on presentation of proper identification. Such a common error can only be corrected 
by the transferor complaining to the transfer organisation, when he is notified of the 
non-delivery by the transferee; the full transfer details have to be taken again from the 
transferor to attempt a further transfer. 

The present invention has been devised bearing the above problems in mind. 

Broadly speaking, a first aspect of the invention is to provide the transferor with 
a secret identifier code (referred to in preferred embodiments as a party identification 
code or PIC) which is supplied to the transferor independently of the information 
exchanged with the transferor when the transferor is making a transfer request (for 
example, in the preferred embodiment, the PIC is sent to the transferor by post). The 
identifier code (or at least information related thereto) can be transmitted as part of the 
money transfer instructions through the money handling authorities. The transferor is 
required to transmit the secret identifier code to the transferee, and the transferee is, in 
turn, required to present the identifier code as one of the conditions to be met before 
the money can be collected by the transferee. Possession of the correct identifier by 
the transferee represents proof that the transferee has been authorised to receive funds 
by the transferor. 

As used herein the term "money handling authority" refers to any authority 
empowered to handle money and, where appropriate, refers to any authority 
empowered to provide funds to a transferee. The term may include, but is not limited 
to, banks, internet banks, post offices, etc. 

Such a technique can avoid the need for the transferee to possess official proof 
of identification, and can also improve security. In particular, the local handling agents 
at the point of sale to the transferor will not have access to sufficient information to 
receive the funds fraudulently. 
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3 

Preferably, the identifier code (PIC) is allocated for at least one of the parties to 
the transfer (i.e. the transferor and/or the transferee). In the preferred embodiment, 
the identifier code (PIC) for the transferor, and the same code is re-used for subsequent 
transfers from the transferor to any transferee. This avoids the need for new identifier 
5 codes to be issued to the transferor for each transaction. 

Broadly speaking, a second closely related aspect of the invention is to generate 
an identifier code (referred in preferred embodiments as a unique transaction code or 
UTC), and to provide the transferor with the code (to be forwarded by the transferor to 
the transferee), but provide the money handling authority instructed to handle the 
10 transfer with second code (referred in the preferred embodiments as a transaction 
verification code or TVC) related verifiably to the identifier code. The second code is 
sufficient to enable the money handling authority to verify that the transferee is 
authorised to receive the funds upon presentation of the complete code by the 
transferee. Upon collection of the funds, the money handling authority can return the 
15 complete identifier code through the banking system, as evidence that the funds have 
been collected by the authorised transferee. 

Such a technique can provide security against a fraudulent "collection* of the 
transfer by the money handling authorities instructed to handle the transfer, since the 
money handling staff will not have access to the complete identifier code to complete 
20 validly the transaction by returning the full code as evidence of completion. If the 
funds are collected fraudulently by a person who has knowledge only of the second 
code (i.e. the TVC), and has therefore had to add a guessed code to the known code, 
this will be readily noticeable when the incorrect code is received back from the money 
handling authority. 

25 Preferably, this aspect of the invention further comprises testing, at least 

selectively or on demand, the full identifier code information returned for each 
completed transfer against the originally allocated identifier code to verify that the 
correct transferee has collected the funds. 
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Although the above aspects can be used independently, particular advantages 
can be achieved by using the two aspects in combination. In particular, the technique 
can then ensure that neither the handling agents at the point of sale, nor the handling 
agents at the point of collection, possess all of the necessary information properly to 
5 complete a transfer. Only the transferor and the transferee possess the necessary codes 
(i.e. the PIC identifier code of the first aspect, and the UTC identifier code of the 
second aspect) needed to complete the transfer. 

In a closely related aspect, the invention provides a method of generating a first 
identifier code (UTC in the preferred embodiments) and a second code (TVC in the 
10 preferred embodiments) related thereto, the method comprising: 

generating the first code such that at least one character thereof represents a 
function of one or more other characters of the first code; 

generating a second code comprising at least one, but not all, of the characters 
of the first code, and comprising information indicative of the position in said first code 
15 of said at least one character and/or of said one or more other characters. 
Preferably, the characters of the first code are numeric. 
Preferably, the function is a checksum (or sum) function. 
Preferably, the second code comprises one or more "blank" characters 
representing missing character or digit positions of the first code. 
20 Preferably, the function is based on characters in one or more predetermined 

positions in the first code, and said information represents the position in said first code 
of the result of the function. 

In the preferred embodiment, the function is numeric sum function of the first 
four digits in the first code, and the information identifies where the result is to be 
25 found in the last four digits of the first code; a first character ( a F w ) denotes that the 
result is in the first one or two digits of the last four; a second character ("M") denotes 
that the result is in the middle one or two digits of the last four; and a third character 
(«L W ) denotes that the result is in the last one or two digits of the last four. It will be 
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appreciated that other indexing systems could be used, for example, depending on the 

number of character positions available for the result. 

In a closely related aspect, the invention provides a method of testing 

information provided by a transferee for collection of funds, the method comprising: 
5 receiving transfer instructions including a first party identifier code allocated to 

at least one of the parties to the transfer, and a second transaction verification code 

related to a transaction identifier code allocated to the transaction; 

(a) comparing the first party identifier code from the transfer instructions with a 

party identifier code provide by the transferee; and 
10 (b) comparing the second transaction verification code with a transaction 

identification code provided by the transferee. 

Preferably, the method further comprises returning the transaction identification 

code to the issuing authority as evidence that the transferee is authorised to receive the 

funds. 

15 Preferably, the transaction verification code contains some, but not all of the 

characters of the transaction identification code, and the method comprises comparing 
each known character in the transaction verification code for equivalency with a 
corresponding character of the transaction identifier code. 

Preferably, the transaction verification code includes information associated 

20 with the result of a function based on one or more characters of the transaction 
identification code, and the method comprises testing whether the transaction 
identification code presented by the transferee matches the function. 

In a closely related aspect, the invention provides a money transfer system 
comprising: 

25 at least one remote input unit operable to generate a money transfer request in 

accordance with information from a transferor; and 

processing means for communicating with each remote unit for receiving and 
processing money transfer requests received therefrom, the processing means 
comprising: 
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means for providing a first identifier code associated with the transaction and/or 
with the identity of one or more parties to the transfer; 

means for outputting first information including the first identifier code, to be 
communicated direcdy or indirectly to the transferor independently of the 

5 communication with the terminal; and 

means for outputting second information to be supplied directly or indirectly to 
a money handling authority as instructions to effect the transfer for collection, the 
second information including at least a portion of the first identifier code or information 
related thereto to enable the authority of the transferee to be verified. 

10 Preferably, the system includes a plurality of terminals. Preferably, the 

processing means (also referred to herein as the server), is able to communicate with 
each terminal at various times during a working day, to control the terminals directly, 
or to upload transfer requests (and any other information) logged by the terminals while 
off-line (if off-line operation is supported). 

15 In a further closely related aspect, the invention provides a money transfer 

system comprising: 

at least one remote input unit operable to generate a money transfer request in 
accordance with information from a transferor; and 

processing means for communicating with each remote unit for receiving and 
20 processing money transfer requests received therefrom, wherein: 

the terminal and/or the processing means is operable to output for 
communication directly or indirectly to the transferor, an identifier code allocated to 
the money transfer; and 

the processing means is operable to output money transfer instructions to be 
25 supplied directly or indirectly to a money handling authority as instructions to effect the 
transfer for collection, the instructions including only a first portion of the identifier 
code, whereby the money handling authority can verify a portion of the identifier code 
presented by the transferee. 
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Preferably, the terminal is operable to output the code to the transferor directly. 
Preferably, the terminal is operable to communicate the identifier code to or from the 
processing means. 

Preferably, the system comprises means for receiving a full identifier code 
5 returned by the money handling authority as evidence of completion of the transfer, and 
means for comparing the returned identifier code with the originally allocated code for 
the transaction. 

Preferably, the system comprises database means for storing the identifier code 
allocated to each transaction. 
10 An embodiment of the invention is now described, by way of example only, 

with reference to the accompanying drawings, in which: 

Fig. 1 is a schematic block diagram illustrating the principles used in the 
embodiment; 

Fig. 2 is a schematic diagram illustrating the information used in Fig. 1; 
15 Fig. 3 is a schematic diagram illustrating generation of a UTC and a TVC; 

Fig. 4 is a schematic block diagram of a remote input unit; 

Fig. 5 is a schematic block diagram of the central server; 

Fig. 6 is a flow diagram illustrating operation of the central server; 

Fig. 7 is a flow diagram illustrating operation of the second embodiment of 
20 terminal; 

Fig. 8 is a flow diagram illustrating information exchange between the terminal 
and the central server during a polling operation; and 

Fig. 9 is a flow diagram illustrating operation of the server for handling 
information from the second embodiment of terminal. 

25 

The principles used in this embodiment are first described briefly with reference 
to Figs. 1 and 2. The system consists of a plurality of remote terminals 10 located, for 
example, in shops and/or banks within a local community. The terminals 10 
communicate with a central processor, also referred to hereinafter as the server 12. 
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The terminals 10 may, for example, be coupled to the server 12 by conventional 
telephone modems which call up the server 12 to be controlled by the server 12. In 
this embodiment, all operations and calculations are performed by the server 12, and 
the terminal 10 acts as a dumb slave unit, i.e. as a remote input and display device. To 
5 improve security, the server 12 may call-back the terminal 10 at a pre-designated 
telephone number to ensure that third parties cannot break into the server operation. 

When a new customer desires to perform a transfer, or desires to be "logged" 
as a customer for future transfers, this can be done at any terminal 10, which calls the 
server 12 to perform the process under to server's control. The customer's details 
10 including his name and address are inputted through the terminal 10 and recorded by 
the server 12 in a customer database 12. The local agent gives the customer a swipe 
card (not shown) which may be coded in any suitable manner, for example, optically, 
magnetically, or carry an electronic circuit. In this embodiment, the swipe card has a 
conventional magnetic strip on which is a pre-recorded code uniquely identifying the 
15 card. The code also doubles as a unique identification code for the customer (and is 
referred to later as the CIC, for customer- or card- identification code). To validate the 
card, the customer or the local agent is required to insert the card into the terminal so 
that the pre-recorded code can be read by the terminal's card reader (not shown) and 
communicated to the server 12 to be recorded in the customer database. 
20 Either immediately, or at some time later, the server 12 allocates a party 

identification code (PIC) for the new customer. The PIC is needed later by a transferee 
to verify that he has been authorised by the transferor to receive the funds. In this 
embodiment, the PIC is generated using a random or pseudo random generator, and 
consists of a numeric code, for example, a four digit code, but an alphanumeric or 
25 purely alphabetic code could be used instead. The PIC is printed using a secure postal 
printer 16, and is posted directly to the customer 14. A significant feature is that the 
PIC is not communicated through the terminal 10, and so the local agent has no means 
of accessing a person's PIC to fraudulently intercept transfers. 
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To perform a transfer, the customer (transferor) 14 presents his swipe card to be 
inserted into the terminal's card reader. This initiates communication between the 
terminal 10 and the server 12 so that the transfer details can be inputted to the server 
12. The transfer details include the name and address of the transferee, the amount to 
5 be transferred, and the name and address of the bank or other money handling authority 
at which the transferee will collect the transferred funds. The latter information can be 
selected from a list or menu of allowable collection authorities for any particular 
country or town. 

The server 12 calculates the amount required to be paid by the transferor, which 
10 the transferor pays to the local agent. The server 12 then allocates a transaction 
identification code for the transfer, in the form of a unique transaction code (UTC). In 
this embodiment, the UTC is based on a pseudo-random code, which is tested to ensure 
that it uniquely identifies the transfer (at least for the period in which the transfer is 
valid; the same code is available for re-use after that period). The code is numeric, but 
15 in alternative embodiments could be alphanumeric, or purely alphabetic. The server 12 
communicates the UTC to the terminal 10, and a hard copy of the transfer details, 
including the UTC, is printed out by the terminal 10 to be given to the transferor as a 
receipt. 

It is the transferor's responsibility to send the PIC and the UTC to the transferee 
20 18 and to ensure that only the intended transferee receives this information. Normally 
this would be done by sending the PIC and the UTC by separate routes (depicted as 20a 
and 20b in Fig. 1), for example, by separate letters, or by communicating one by letter 
and the other by telephone or telex. The UTC and the PIC together provide the 
transferee with all of the information needed to validate the transaction, and collect the 

25 transferred funds. 

To effect the transfer, the server 12 communicates a transfer request 22 directly 
or indirectly (for example through a remote terminal) to a computer 24 of a domestic 
bank (assuming that the transfer system is being run by an independent organisation 
using the bank as an intermediary). The transfer request 22 includes the transfer details 
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supplied by the transferor, and also includes the PIC and a transaction verification code 
(TVC). The TVC is related to the UTC to enable verification of the correct UTC when 
presented by the transferee, but the TVC does not itself contain sufficient information 
to enable the original UTC to be deduced if it is not known. The bank computer 22 
5 processes the transfer request and communicates the transfer information 26, by 
conventional bank transfer services, for example by telex, or by SWIFT, to the foreign 
bank 28 nominated by the original instructions from the transferor 14. The transfer 
information 26 supplied to the foreign bank includes the PIC and the truncated TVC. 

In order to collect the transferred funds, the transferee 18 visits the foreign bank 
10 28 and presents the PIC and full UTC. The PIC provides evidence that the person has 
been authorised by the transferor to receive funds, and the full UTC provides the 
necessary authorisation to complete the transaction. The staff at the foreign bank 28 
are able to compare transferee's UTC with the TVC with which they have been 
supplied to verify that the full UTC matches the TVC. The foreign bank 28 then 
15 returns the full UTC to the domestic home bank 24 as evidence that the transfer has 
been properly completed, and that the correct recipient has been paid. 

Such a system offers important advantages over conventional techniques: 
(a) The transferee does not require any form of personal identification, such as a 
passport, or a driving licence. 
20 (b) The only parties in possession of all of the necessary information validly to 
complete a transaction are the transferor, and the transferee. The agents at the point of 
sale (10) do not have access to the PIC, since this is allocated directly by the server 12, 
and is communicated to the transferor by post. The staff at the domestic home bank 24 
and at the foreign bank 28 have access to the PIC, but do not have access to the full 
25 UTC. This will obstruct any fraudulent activity by the handling authorities or agents, 
(c) It is the responsibility of the transferor to transmit the PIC and the full UTC to 
the transferee in a secure manner. If this information is intercepted and the funds are 
collected fraudulently by a third party, then neither the money handling authorities, nor 
the money transfer organisation, has to accept liability. 
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For subsequent transfers from the same transferor 14, the original PIC is 
reused. The server 12 maintains a database of transferors and the PIC allocated to 
each. New PIC's are only allocated, printed and posted for new transferors, or if a 
transferor believes his PIC to have been compromised. 
5 In general, a transferor will only have to notify his PIC to a transferee once. 

Once the transferee knows the PIC, all he needs to receive funds is the new UTC 
associated with each individual transaction. This further reduces the chances of 
information being intercepted between the transferor 14 and the transferee 18. 

There are numerous techniques for generating a TVC which relates verifiably to 

10 the UTC but does not prejudice the security of the UTC. For example, one technique 
is to truncate, or blank, one or more digits or characters from the UTC, leaving a code 
which partly matches the full UTC. The security can be improved by varying the 
number and/or the positions of the blanked characters, so that a person will not be able 
to predict which of the characters of the code are already known in the TVC. 

15 Another technique for generating a TVC is generate one or more checksum 

digits or characters. These can either be included in the UTC, or they can be included 
only in the TVC. The security can be improved by varying the number and/or the 
positions of the characters or digits on which the checksum is based, so that a person 
will not be able to predict which characters represent, or contribute to, the checksum. 

20 In a particularly preferred embodiment, the TVC is generated by a combination 

of the above two techniques. Referring to Fig 3, the UTC can consist of a 7, 8, 9 or 
10 digit code, for example the code illustrated in Fig. 3a. This is based on a pseudo- 
random number, but tailored such that the sum of the first four digits A is represented 
somewhere in the last four digits, namely in the first one or two digits B of the last 

25 four, or the middle one or two digits C of the last four, or the last digit or digits D. In 
the illustrated code, the sum (i.e. 8+4+5+9=26) is represented in the middle two 
digits C of the last four. 

Fig. 3b illustrates a first TVC which may be generated from the UTC. The 
TVC includes some of the original digits, the missing digits being replaced by "blank" 
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characters. The TVC also includes a prefix code "F", "NT or "L w to indicate whether 
the sum is to be found in the First, Middle or Last digits of the last four digits. In the 
present example, the sum is in the middle digits C of the last four, and this is denoted 
in the TVC by prefix "M". It will be appreciated that the prefix code is only included 
5 in the TVC, and not in the UTC. 

When the UTC is presented for verification, the local bank can check firstly 
whether the digits in the UTC agree with the digits already known in the TVC, and 
secondly, whether the appropriate checksum digits denoted by the TVC's prefix 
correspond to the sum of the first four digits. 
10 Fig. 3c illustrates a second TVC which may be generated for the same UTC. 

The prefix code is, of course, the same as that for Fig. 3b, but this example illustrates 
that a person cannot predict which digits are known in the TVC, since this can vary. 

The above scheme represents a balance between security and ease of verification 
at a remote bank. Other schemes may be used which require computer verification, but 
15 this could restrict the banks at which the transferee is able to collect the funds. 

Referring to Fig. 4, the remote unit 10 comprises a main processor 30 to which 
are connected a display screen 32, a keyboard 34, a swipe card reader 38, a receipt 
printer 40, a customer/transaction logger 41, and a telephone communications modem 
44 coupled through an encryption/decryption unit 46 for communicating with the server 
20 12. The display screen may, for example, be a video display unit, or it may be an 
alphanumeric display, for example, an LCD display. The display is used to present 
messages and prompts to the customer (transferor) and/or the local agent supervising 
the remote terminal 10, in response to instructions from the server 12. The details of 
the transaction and, if the customer is a new customer, the customer's details, are 
25 entered using the keyboard 34. 

The logger 41 provides a summary of information inputted through the terminal 
10 during a working day, so that end-of-day information can be generated and checked 
by the server 12. 
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The logger 41 and the encryption/decryption unit 46 are illustrated above as 
discrete units for ease of description. However, it will be appreciated that these units 
may be embodied by software running on the main processor 30. 

Referring to Fig. 5, the server 12 consists generally of a central processor unit 

5 90 to which are connected a customer database 92, a transaction database 94, a 
reference database 96, a PIC generator 98, a UTC/TVC generator 100, a secure postal 
printer 102, an output system 104 (for passing transfer instructions to a bank 
computer), an input cache 106, and a telephone modem 108 connected through an 
encryption/decryption unit 110 (which is similar to the encryption/decryption unit 46 

10 described above for the remote terminal 10). 

The customer database 92 is a master database of all customers (transferors) 
who have used the system at any time. For each customer, the database also includes 
full name and address information, at least limited transaction history, and the 
customer's PIC and CIC. The transaction database 94 is a master database of the 

15 transactions. This includes all pending transactions, and possibly at least a limited 
history of completed transactions. The information in the transaction database 94 may 
be archived from time to time to make more memory available for new transactions. 
The reference database 96 is a master database of the current reference information 
required for the transactions, including, for example, the countries to which transfers 

20 can be sent, available recipient bank details for each country, currency exchange rates 
and commission rates. 

The secure postal printer 102 is of a known type which is able to produce sealed 
envelopes containing a printed sheet, it being possible to read the sheet only by 
breaking open the sealed envelope. Such printers are used in applications where it is 

25 desired to print information securely to send to a recipient, while ensuring that local 
staff are unable to read the contents of the envelope. 

Fig. 6 illustrates the operation of the server 12 once communication has been 
established between a terminal 10 and the server 12. Step 122 determines whether the 
information from the terminal 10 corresponds to a new or existing customer. This is 
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apparent if the information contains an existing customer identification code CIC. 
Assuming as a first case that the information does correspond to a new customer, then 
the process proceeds to step 123 at which the server 12 controls the terminal to prompt 
for, and return, inputted customer information, including the customer's full name and 

5 address. At step 124 a new customer entry is created in the customer database 92. 

From step 124, the process proceeds to step 125 at which the server 12 controls 
the terminal to prompt for a new swipe card to be introduced into the terminal's card 
reader 38. As explained hereinbefore, the swipe card carries a pre-recorded CIC, which 
is read by the terminal 10 and returned to the server 12. At step 126, the read CIC is 

10 recorded in the customer database. This completes the introduction of a new customer 
at the terminal 10. The customer can then use the swipe card to initiate a transfer. 

At step 127, a PIC is generated for the new customer by the PIC generator 98. 
As explained previously, the PIC is used later by the recipient to identify himself at his 
local bank to collect the transferred funds. A separate PIC is generated for each 

15 customer. In the present embodiment, the PIC is produced as a random or pseudo- 
random 4-digit number, so that it is impossible to derive any relationship between the 
PIC and the customer's details (which might otherwise enable PIC's to be predicted by 
fraudulent parties). However, in other embodiments, the PIC could be the result of a 
checksum or hashing function carried out on the customer's name or address, so that it 

20 is possible to verify whether given PIC matches given party's name. Alternatively, it 
is possible to generate a pseudo random PIC using an encryption algorithm which is 
virtually impossible to reverse or to predict, but which retains a verifiable relationship 
with the parties names. However, in the present embodiment, it is assumed that it may 
be difficult to arrange for verification of the PIC by the recipient's bank, and so it is 

25 preferred to utilise a completely random PIC. 

At step 128, the PIC is recorded in the customer database. The PIC is also 
printed in a sealed envelope by the secure printer 102, and the envelope is addressed 
and posted to the customer at his home address identified in the customer information 
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received from the remote terminal 10 (and now stored in the customer database 92 of 
the server 12). 

It will be appreciated that steps 127 and 128 can be carried out either 
immediately after communication with the terminal 10, or at some subsequent time 
5 when the server 12 may be less busy. 

If at step 122 the received information contains an existing CIC (and therefore 
corresponds to an existing customer, the process proceeds to step 130 at which the 
customer's PIC is retrieved from the customer database. At step 132, the transfer is 
analysed to assess whether it is a suspicious transfer which should be stopped for legal 
10 reasons. Suspicious transfers may, for example, be detected as any of the following: 

(i) transfers greater than a certain allowable amount (which may vary depending 
on the destination country); 

(ii) repeated transfers which accumulate to a sum greater than an allowable 
amount over a predetermined period (the amount may vary depending on the 

15 destination country); 

(iii) repeated transfers the frequency of which exceeds an allowable figure 
(which may very depending on the destination country). 

The purpose of step 132 is to provide at least a degree of protection to prevent 
large scale money laundering or illegal funds transfer from one country to another. If a 
20 suspicious transfer is detected, then the transfer process can be aborted, or the server 
12 can prompt the terminal 10 that proof of identification is required before the transfer 
can proceed. Details of the proof of identification (e.g. a passport number) can be 
entered at the terminal 10 for communication back to the server 12. 

At step 134, a check is performed on whether the customer's payment has yet 
25 cleared. If cash is used to pay for the transfer, then this step can be omitted. 
However, if payment has been made by cheque, then no transfer should be authorised 
until the cheque has been cleared by the customer's bank. If the payment has not yet 
cleared, then the data is re-stored (for example, in the input cache 106 or in a separate 
pending store) to be re-processed during the next day's processing. 
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At step 135, the UTC and the TVC for the transfer are provided. These could 
either be generated "live", for example, by suitable algorithms, or the UTC and the 
TVC could be obtained from a supply of pre-generated codes. Such codes could be 
pre-generated when the server 12 is not busy, for example, overnight, and stored in 
5 suitable memory. 

At step 136, the UTC is communicated from the server 12 to the terminal 10 to 
be printed by the terminal 5 s printer 40. This provides the customer (transferor) with 
the UTC to send to the transferee. 

At step 137, the transfer details are issued as a transfer instruction to the 
10 intermediary bank. The transfer instructions include the transfer details originally 
inputted by the customer, the PIC, and the TVC (including the prefix code *F", "NT 
or «L"). 

At step 138, the transaction details are stored in the transaction database 94 as a 
pending transaction, which completes the initial transaction processing. Although not 
15 illustrated in the drawings, additional processing can be provided when the foreign 
bank returns the full UTC as evidence that the transaction has been completed. The 
returned UTC can be compared to the UTC recorded in the transaction database to 
verify that the transaction has been completed correctly. Alternatively, this verification 
step might only be necessary if a transferor complains of non-delivery of funds to the 
20 transferee, or of collection by an unauthorised person. 

In Fig. 5, the encryption/decryption unit 110, the input cache 106, the PIC 
generator 98, the UTC generator 100, the TVC generator 101, and the databases 92, 94 
and 96 are illustrated as separate "items" from the server processor 90. This is merely 
to aid description of the invention. It will be appreciated that these functional parts may 
25 be implemented by software applications running on the processor. 

Although not illustrated in the drawings, it may also be possible for a customer 
to place a telephone order to a telephone receptionist, who would then enter the transfer 
details using a dedicated terminal, or directly on to the server 12. The UTC could be 
issued to the telephone transferor either by telephone, or by means of the secure postal 
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printer 102. In the latter case, it is preferred that the UTC be printed and posted 
separately from any communication of a new PIC, to reduce the chances of these items 
of information being intercepted together. 

The above embodiment employs "online" operation of the terminals 10 under 

5 the direct control of the server 12. All of the information processing is carried out by 
the server 12. This can enable relatively inexpensive and straightforward terminals to 
be used, and it can also enable updated information to be available immediately simply 
by changing the information and/or the programs on the server. 

In an alternative embodiment, it may be desirable to provide at least some of the 

10 terminals with a degree of autonomy, for offline operation. Referring to Fig. 4, the 
terminal 10 is similar to that previously described, but includes the following units 
(shown in phantom): a UTC/TVC generator 48; a reference database 36; and a 
customer/transaction database 42. The reference database 36 provides reference 
information for the remote terminal, such as details of the individual countries to which 

15 transfers can be sent, and the individual banks in each country, the exchange and 
commission rates for each country, and the likely transfer delay for each country (if a 
calculation of the expected arrival date of the funds is to be provided). The reference 
database may also include details of public holidays in each country, and the allowable 
methods of payment by the customer (for example, cash, cheque, credit card, e-cash, 

20 mondex, etc.) and the clearance delay for each type of payment (if the calculation of 
the expected arrival date of the funds is to be provided). The information in the 
reference database can be updated periodically by the server 12, for example, at the 
start of a day, or during routine polling of the terminal 10 by the server, as described 
further below. 

25 The customer/transaction database 46 is used to store details of transfer 

requests, and details of any new customers, until the information can be uploaded to the 
server 12 for action. 

Referring to Fig. 7, before a new customer can use the transfer system, the 
customer's details have to be entered into the terminal using the keyboard (step 50). 
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The customer details include the customer's name and address (or other contact 
details), so that the secure PIC can be sent later to the customer by the server 12. The 
customer details are then stored in the customer/transaction database 42 (step 52). 
Thereafter, the- customer is issued with a swipe card (step 54) which carries a unique 

5 customer identification code (CIC), as explained previously. 

At step 56, the customer (or the local agent) enters details of the desired 
transfer. Such details include the name and address of the recipient (transferee), the 
amount to be transferred (in the local currency of the customer), the method of 
payment by the customer, and the destination country, name and address of the bank or 

10 other money handling agent at which the recipient will collect the transferred funds. 

At step 58, the processor 30 calculates and displays the value of the funds in the 
recipient's currency, and the amount of commission charged, based on the information 
stored in the reference database 36. If desired, the processor may also calculate an 
estimated date of arrival of the transferred funds at the destination bank, using 

15 information in the reference database, and the following formula: 

Arrival date = today's date + funds clearance delay + transfer delay + calendar 
(holiday) delay 

20 If the customer agrees to the transaction and makes payment to the agent, then 

this is confirmed at step 60. (If the customer declines to proceed, then the process can 
be aborted at this step.) Thereafter, at step 61 the UTC and TVC for the transfer are 
provided/generated by the UTC/TVC generator 48. The UTC and TVC can either 
being generated "live", or a pre-generated UTC and TVC can be retrieved. Such 

25 UTC's and TVC's may either be generated by local generators within the terminal, or 
they may be downloaded from the server 12 as part of the update information for the 
reference database. 

At step 62, the transfer details including the allocated UTC are stored in the 
customer/transaction database 42 to await uploading to the server 12 for processing. 
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The transfer details including the UTC are also printed out (step 64) by the terminal's 
receipt printer 40 to provide a receipt for the customer. 

The above method steps apply to a new customer. An existing customer simply 
inserts his or her swipe card into the terminal's card reader 38 (step 66), at which stage 

5 the customer number is read from the card. This provides sufficient information for 
the server 12 to access the customer's details which are stored in the server 12. After 
step 66, the process proceeds directly to step 56 for the customer (or agent) to enter the 
details of the transfer, as described above. 

At various intervals during the day, the terminal 10 is polled by the server 12 by 

10 telephone, to upload money-transfer information and new customer information to the 
server 12, and to receive new reference information from the server 12. Referring to 
Fig. 8, when a telephone call is received from the server 12 (step 70) the process 
proceeds to step 172 at which the terminal 10 verifies that the call is from the proper 
server 12, for example, by means of a secret password. The terminal also returns a 

15 secret password, so that the server 12 can verify that it is communicating with the 
proper terminal 10. It will be appreciated that all information sent and received 
through the telephone line is communicated in encrypted form, so that the information 
cannot easily be intercepted. At the terminal end, the information is 
encrypted/decrypted by the encryption/decryption unit 46 connected between the 

20 processor 30 and the modem 44. 

Following step 72, the terminal waits to receive any new reference information 
(step 74) for the reference database 36. Such new information may be in the form of a 
replacement "reference" file to overwrite the entire existing contents of the reference 
database 36, or it may be in the form of update "packets" to replace only certain 

25 information in the reference database. The new information (if any) is then written into 
the database. 

At step 78, the terminal transmits the new contents of the customer/transaction 
database 42 to the server 12. This new information includes details of any new 
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customers (including the customer identification number for each new customer), and 
details of transfer requests entered by the customers. 

Step 80 determines whether the terminal has closed at the end of the day and, if 
so, the process proceeds to step 82 at which end-of-day (EOD) information is 

5 transmitted to the server 12. The EOD information includes totals representing the 
day's transactions and new customers, to provide a cross-check that all of the terminal's 
information has been validly received by the server 12. This is subsequently cross- 
checked by the server 12. If the terminal has not yet closed at the end of the day, then 
the process branches past step 82, to step 84 at which the communication is terminated. 

10 The server 12 will normally poll each terminal 10 at several different times 

during the day. During each communication session, the terminal transmits only the 
new information contained in the customer/transaction database 42 (i.e. the information 
not previously communicated to the server). In this embodiment, the information 
remains in the customer/transaction database 42 until after the server 12 verifies, for 

15 example, by means of the EOD information, that all of the information has been 
uploaded correctly to the server 12. Such a technique enables all of the information to 
be uploaded to the server again if necessary, for example, should any discrepancies 
arise from the EOD information. However, in other embodiments, the 
customer/transaction database 42 could be cleared after each communication session 

20 with the server 12, if desired. 

In Fig. 4, the reference database 36, the customer/transaction database 42, the 
encryption/decryption unit 46 and the UTC/TVC generator 48 have been illustrated as 
distinct "items" from the processor unit 30. This presentation is merely schematic to 
aid description of the invention. It will be appreciated that such items may be 

25 implemented as application software run by the processor unit. The reference 
information and the customer/transaction information may be stored as files on 
conventional mass storage, for example, a semiconductor mass memory or a magnetic 
disc. 
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In use, the server 12 polls each remote terminal 10 to download updated 
reference information to the terminal 10, and to upload new transfer-request 
information and new-customer information from the terminal. The communication 
procedure is complementary to that described above with reference to Fig. 8, and so is 

5 not expanded further here. The uploaded information is stored temporarily in the input 
cache 106 until it can be processed by the processing unit 90. 

Fig. 10 illustrates the manner in which each "packet" of information from the 
input cache 106 is processed. Where appropriate the same reference numerals as those 
in Fig. 6 are used to denote an equivalent operation step. The information is firstly 

10 read from the cache 106 at step 120 and, as before, step 122 determines whether the 
information corresponds to a new customer. Assuming as a first case that the 
information does correspond to a new customer, then the process proceeds to step 124 
at which a new customer entry is created in the customer database 92, containing the 
CIC read from the input cache. 

15 From step 124, the process proceeds to step 127 at which a PIC is generated for 

the customer. 

At step 128, the PIC is printed in a sealed envelope by the secure printer 102, 
and the envelope is addressed and posted to the customer at his home address identified 
in the customer information received from the remote terminal 10 (and now stored in 
20 the customer database 92 of the server 12). The PIC is also stored in the customer 
database 92. 

Step 132 represents the first step for processing the transfer after the customer 
and recipient details have been stored. At step 132, the transfer is analysed to assess 
whether it is a suspicious transfer which should be stopped for legal reasons, as 
25 explained in more detail hereinbefore. 

At step 134, a check is performed on whether the customer's payment has yet 
cleared. Assuming that the payment has cleared, the process proceeds to step 136 at 
which the transfer details are issued as a transfer instruction to the intermediary bank. 
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The transfer instructions include the transfer details originally inputted by the customer, 
the PIC, and the TVC received from he terminal 10. 

At step 138, the transaction details are stored in the transaction database 94 as a 
pending transaction, which completes the initial transaction processing. 
5 If at step 122, the information corresponds to an existing customer, the process 

proceeds to through step 142 at which the existing PIC for the customer is read from 
the customer database for re-use. The process then proceeds through step 132 for 
processing of the transfer details, as described above. 

In the above embodiment, the UTC and TVC are allocated to the transaction at 
10 the point of sale terminal 10, to provide offline operation of the terminal 10. Although 
in the illustrated embodiment, the TVC is allocated at the terminal, this could instead 
be allocated by the server 12, to reduce the risk that the TVC might be available by 
tapping into the terminal somehow. 

In the above embodiments, the PIC is associated only with the transferor. In an 
15 alternative form, the PIC could be associated instead with each transferor/transferee 
pair. Thus instead of a transferor having a single PIC, the transferor would have 
different PIC's for his different transferees. This could provide additional security if 
needed, but might require the transferor to remember possibly a large number of PIC's. 
The customer database would also need to store all of the PIC's for each transferor, 
20 and be able to identify subsequent transactions between the same transferor and 
transferee, in order to use the correct PIC. 

In the above embodiments, swipe card is pre-programmed with its CIC, and this 
is the only information required to be read by the terminal. In other embodiments, the 
terminal might be equipped with a card reader/writer for writing information to the 
25 card as well as reading it from the card. This could enable "favourite recipient" data to 
be stored on the swipe card in order to simplify the operation for the transferor. 

It will be appreciated that the invention, particularly as illustrated in the 
preferred embodiments, can enable funds to be transferred in a logical and secure, 
manner, which allows a recipient to receive the funds without having to have official 
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proof of identity (such as a passport). Only the transferor and the intended transferee 
have access to sufficient information to complete the transfer, and it is the transferor's 
responsibility to ensure that the information is sent in a secure manner to the transferee. 
Neither the local handling agent for the transferor, nor the local handling agent for the 
5 transferee, have direct access to sufficient information to complete a valid transfer. 

While features believed to be of importance have been identified in the 
foregoing description, and in the appended claims, the applicant claims protection for 
any novel idea, feature or combination of features described herein and/or illustrated in 
the drawings irrespective of whether emphasis has been placed thereon. 
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CLAIMS 

1. A method of handling money transfer requests in a system which includes at 
least one input device for receiving information directly or indirectly from a transferor, 
5 and processing means for communicating with the input device for processing money 
transfer requests therefrom, the method comprising: 

receiving at the processing means a money transfer request from the input 

device; 

providing within the processing means a first identifier code for the transfer 
10 and/or for at least one of the parties to the transfer; 

sending the first identifier code directly or indirectly to the transferor if the first 
identifier code is a new code, the sending operation to the transferor being an 
independent operation from the communication with the input device; 

outputting money transfer instructions including at least a portion of the first 
15 identifier code or information related thereto; and 

communicating the money transfer instructions to a money handling authority as 
instructions to effect the money transfer, whereby the authority of the transferee party 
to receive the funds can be verified upon presentation of the first identifier code by the 
transferee party. 

20 

2. A method of operation in processing means for processing money transfer 
requests, the method comprising: 

receiving at the processing means information representing a money transfer 

request; 

25 providing within the processing means a first identifier code associated with the 

transfer and/or with at least one or the parties to the transfer; 

sending the first identifier code directly or indirectly to the transferor if the first 
identifier code is a new code; 
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outputting money transfer instructions including at least a portion of the first 
identifier code or information related thereto; and 

communicating the money transfer instructions to a money handling authority as 
instructions to effect the money transfer, whereby the authority of the transferee party 
5 to receive the funds can be verified upon presentation of the first identifier code by the 
transferee party. 

3. A method of communicating information with a transferor for a money transfer 
operation to transfer money to a transferee, the method comprising; 
io (a) receiving transfer instruction information directly or indirectly from the 

transferor; 

(b) providing a first identifier code associated with the transfer and/or with 
at least one of the parties to the transfer, the code being required by the transferee to 
complete the money transfer operation; 
15 (c) outputting or selectively outputting the first identifier code for 

communication to the transferor; 

wherein in step (c) the first identifier code is outputted for confidential 
communication to the transferor independently of the communication in step (a). 

20 4. A method according to claim 3, wherein step (c) comprises selectively 
outputting the first identifier code if the code is newly allocated. 

5. A method according to claim 1, 2, 3 or 4, wherein the step of providing the 
first identifier code comprises selectively allocating a new identifier code, or re-using a 
25 previously allocated identifier code. 



6. A method according to claim 5, wherein the party identifier code is associated 
with the transferor. 
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7. A method according to claim 6, wherein the processing means comprises a 
database of transferors, the database containing for each transferor the or a party 
identification code associated therewith. 

5 8. A method according to any preceding claim, wherein the step of allocating a 
new first identifier code comprises generating a random or pseudo random code. 

9. A method according to any preceding claim, fiirther comprising generating a 
second identifier code associated with the transaction, and outputting the second 
10 identifier code to the transferor, and wherein the step of generating the money transfer 
instructions at the processing means comprises including a verification code related to 
the second identifier code to enable the correct second identification code to be verified 
when presented by the transferee. 

15 10. A method according to claim 9, wherein the second identifier code is outputted 
to the transferor at the or a remote terminal. 

11. A method of handling money transfer requests in a system which includes 
processing means for processing money transfer requests, the method comprising: 
20 generating an identifier code associated with a transfer request; 

outputting the identifier code for communication to the transferor; 

outputting from the processing means money transfer instructions including a 
verification code related verifiably to the identifier code; 

communicating the money transfer instructions to a money handling authority as 
25 instructions to effect the money transfer, whereby the authority of the transferee party 
to receive the funds can be verified at least partly upon presentation of the original 
identifier code matching the incomplete code in the money transfer instructions. 
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12. A method according to claim 11, wherein the identifier code is based on a 
random or pseudo random code. 

13. A method according to claim 11 or 12, wherein the money transfer request is 
generated at a terminal remote from the processing means, and the identifier code is 
outputted at the terminal for the transferor. 

14. A method of operation in a processing means for processing money transfer 
requests, the method comprising: 

receiving at the processing means information representing a money transfer 

request; 

providing an identifier code; 

providing a verification code related verifiably to the identifier code, the 
verification code being insufficient to enable the identifier code to be deduced 
unambiguously therefrom; and 

outputting from the processing means money transfer instructions including the 
transaction verification code, for communication to a money handling authority as 
instructions to effect the money transfer, whereby the authority of the transferee party 
to receive funds can be verified at least partly upon presentation of the original 
identifier code matching the verification code in the money transfer instructions. 

15. A method according to claim 11, 12, 13, 14 or 15, wherein the identifier code 
is generated such that at least one character thereof represents a function of one or more 
other characters of the identifier code, and the step of providing the verification code 
comprises generating a code comprising at least one, but not all, of the characters of 
the identifier code and including information indicative of the position in said identifier 
code of said at least one character and/or of said one or more other characters. 
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16. A method according to claim 15, wherein the characters in the identifier code 
are numeric. 

17. A method according to claim 15 or 16, wherein the function is a sum function. 

5 

18. A method according to claim 15, 16 or 17, wherein the verification code 
comprises one or more blank characters representing missing character or digit 
positions of the identifier code. 

io 19. A method according to claim 15, 16 or 17, wherein the function is based on 
characters in one or more predetermined positions in the identifier code, and said 
information represents the position in said identification code of the result of the 
function. 

15 20. A method according to any preceding claim, further comprising storing the or 
each identifier code at the processing means. 



21. A money transfer system comprising: 

at least one input unit operable to generate a money transfer request in 
20 accordance with information from a transferor; and 

processing means for communicating with the or each input unit for receiving 
and processing money transfer requests therefrom, the processing means comprising: 

means for providing a fist identifier code for the transaction and/or for the one 
or more parties to the transfer; 
25 means operable to output first information including the first identifier code, to 

be communicated directly or indirectly to the transferor independently of the 
communication operation with the input unit; and 

means for outputting money transfer instructions including at least a portion of 
the first identifier code or information related thereto, for communication to a money 
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handling authority as instructions to effect the money transfer, whereby the authority of 
a transferee party to receive the funds can be verified at least partly by presentation of 
the first identifier code by the transferee party. 

22. A system according to claim 21, comprising at least one remote input unit. 

23. A processing system for use in a money transfer system for processing money 
transfer requests, the processing system comprising: 

means for receiving information representing a money transfer request; 

means for providing a fist identifier code associated with the transaction and/or 
with one or more parties to the transfer; 

means operable to output first information including the first identifier code, to 
be communicated directly or indirectly to the transferor; 

means for outputting money transfer instructions including at least a portion of 
the first identifier code or information related thereto, for communication to a money 
handling authority as instructions to effect the money transfer, whereby the authority of 
a transferee party to receive the funds can be verified at least partly by presentation of 
the first identifier code by the transferee party. 

24. A system for communicating information with a transferor for a money transfer 
operation to transfer money to a transferee, the system comprising: 

means for receiving transfer instruction information directly or indirectly from 
the transferor; 

means for providing a first identifier code associated with the transfer and/or 
with at least one of the parties to the transfer, the code being required by the transferee 
to complete the money transfer operation; and 

means for outputting the first identifier code for confidential communication to 

the transferor. 
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25. A system according to claim 24, wherein the means for outputting information 
for the transferor comprises means for selectively outputting the first identifier code if 
the code is newly allocated. 

5 26. A system according to claim 21, 22, 23, 24 or 25, wherein the means for 
providing the first identifier code comprises means for selectively allocating a new 
identifier code, or re-using a previously allocated identifier code. 

27. A system according to claim 26, wherein the first identifier code comprises a 
10 party identification code associated with the transferor. 

28. A system according to claim 27, wherein the processing means comprises a 
database of transferors, the database containing for each transferor the or a party 
identification code allocated thereto. 

15 

29. A system according to any of claims 21 to 28, wherein the means for allocating 
a new first identifier code comprises means for generating a code based on a random or 
pseudo random code. 

20 30. A system according to any of claims 21 to 31, further comprising means for 
generating a second identifier code associated with the transaction, and outputting the 
second identifier code to the transferor, and wherein the means for generating the 
money transfer instructions at the processing means comprises means for including a 
verification code related to the second identifier code to enable the correct identifier 

25 code to be verified when presented by a transferee. 

31. A system according to claim 32, wherein the second identifier code is outputted 
to the transferor at the or a remote terminal. 
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32. A system for handling money transfer requests, comprising: 

at least one input device for receiving transfer request information directly or 
indirectly from a transferor, 

means for allocating an identifier code associated with the transfer request; 

means for outputting the identifier code for the transferor, the code being 
required by a transferee to complete a valid money transfer; and 

means for providing a verification code related to the identifier code, the 
verification code being insufficient to enable the identifier code to be deduced 
therefrom unambiguously, 

means for outputting money transfer instructions including the verification code 
for communication to a money handling authority, as instructions to effect the money 
transfer, whereby the authority of a transferee party to receive the funds can be verified 
at least partly upon presentation of the original identifier code matching the verification 
code in the money transfer instructions. 

33. A system according to claim 32, wherein the identifier code is generated as, or 
is based on, a random or pseudo random code. 

34. A system according to claim 32 or 33, wherein the input device is a remote 
terminal. 

35. A processing system for processing money transfer requests, the system 
comprising: 

means for receiving information representing a money transfer request; 

means for allocating a transaction identifier code for communication directly or 

indirectly to a transferor; 

means for providing a verification code related to the transaction identifier code, 
the verification code being insufficient to enable the identifier code to be deduced 
unambiguously therefrom; 
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means for outputting money transfer instructions including the verification code, 
for communication to a money handling authority as instructions to effect the money 
transfer, whereby the authority of the transferee party to receive funds can be verified 
at least partly upon presentation of the original identifier code matching the incomplete 
5 code in the money transfer instructions. 

36. A terminal for receiving money transfer requests, and for communicating 
transfer request information to a central processor, the terminal comprising: 

input means for receiving information regarding the transfer and the parties to 
10 the transfer; 

means operable to allocate and/or to receive a transaction identifier code; 
means for outputting the transaction identifier code for communication to the 
transferor; 

means for storing information relating to the requested money transfer, said 
15 information including the allocated identifier code; and 

means for communicating with a said central processor. 



37. A terminal according to claim 36, wherein the input device comprises a card 
reader for reading information on a card presented thereto. 

20 

38. A terminal according to claim 37, wherein the card reader comprises a magnetic 
card reader. 

39. A method of handling a money transfer request, comprising: 

25 receiving transfer request information directly or indirectly from a transferor; 

allocating a transaction identification code for the transfer request; 
providing a party identifier code associated with one or more parties to the 
transaction; 
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communicating at least the transaction identifier code to the transferor, to be 
forwarded by the transferor to the transferee; 

communicating money transfer instructions to a money handling authority to 
effect the transfer, the money transfer instructions including information relating to the 
5 transaction identifier code and information relating to the party identifier code, but at 
least one of the codes being incomplete such that the money transfer instructions do not 
contain sufficient information to complete a valid transfer; 

whereby the authority of a transferee to receive the funds can be verified by the 
money handling authority upon presentation by the transferee of the original transaction 
10 identifier code and me original party identification code, which match the information 
in the money transfer instructions. 

40. A method according to claim 39, wherein the step of communicating 
information to the transferor comprises selectively communicating the party identifier 
15 code. 



20 



25 



41. A method according to claim 40, wherein the step of communicating 
information to the transferor comprises communicating the party identifier code if the 
party identifier code is newly allocated. 

42. A method according to claim 40 or 41, wherein the step of communicating 
information to the transferor comprises not communicating the party identifier code if a 
party identification code has previously been allocated for an earlier transaction 
between the same parties, and is to be re-used for the current transaction. 

43. A method according to any of claims 47 to 49, wherein the party identification 
code, if communicated to the transferor, is communicated independently of the 
transaction identifier code. 
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44. A method of testing information provided by a transferee for collection of 
funds, the method comprising: 

receiving transfer instructions including a first party identifier code allocated to 
at least one of the parties to the transfer, and a second transaction verification code 
related to a transaction identifier code allocated to the transaction; 

(a) comparing the first party identifier code from the transfer instructions with a 
party identifier code provided by the transferee; and 

(b) comparing the second transaction verification code with a transaction 
identification code provided by the transferee. 

45. A method according to claim 44, further comprising returning the transaction 
identification code to the issuing authority as evidence that the transferee is authorised 
to receive the funds. 

46. A method according to claim 44 or 45, wherein the transaction verification code 
contains some, but not all of the characters of the transaction identification code, and 
the method comprises comparing each known character in the transaction verification 
code for equivalency with a corresponding character of the transaction identifier code. 

47. A method according to claim 44, 45 or 46, wherein the transaction verification 
code includes information associated with the result of a function based on one or more 
characters of the transaction identification code, and the method comprises testing 
whether the transaction identification code presented by the transferee matches the 
function. 

48. A method or apparatus for handling money transfer requests, being substantially 
as hereinbefore described with reference to any of the accompanying drawings. 
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ABSTRACT 

METHOD AM) APPARATUS FOR MONEY TRANSFERS (Fig. 1) 

5 A money transfer system comprises remote terminals (10) for receiving transfer 

request information from a transferor (14). If the transferor is a new customer, a 
central server (12) generates a new party identifier code (PIC) using a secure postal 
printer (16), to send the PIC to the transferor independently of the communication with 
the terminal (10). The PIC will be re-used for subsequent transfers from the 

10 transferor. For each transaction, the server (12) allocates a unique transaction code 
(UTC) which is outputted to the transferor at the terminal (10). The server also 
generates money transfer instructions (22) communicated to the remote money handling 
authorities (28). The instructions include the existing or newly allocated PIC, 
verification code (TVC) related to the UTC, but insufficient to enable the UTC to be 

15 deduced therefrom. It is the transferor's responsibility to communicate the UTC and 
the PIC to the transferee (18), preferably by separate routes for security. If the parties 
have taken place in a previous transfer, then the transferee will already know the PIC 
from the previous transfer. The transferee can pick up the money from the bank upon 
presentation of the correct PIC and PIN matching the information in the money transfer 

20 instructions. 
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are acceptable as minimums for identifying a specification and compliance with any one of the items 
below wilt be accepted as complying with the identification requirement of 37 CFB 1.63: 

m (1) name of inventors), and application number (consisting of the series code and the serial 
number; e.g.,08/1 23,456); 

'(2) name of inventorfs), serial number and filing date; 

m {3) name of inventors) and attorney docket number which was on the specification as filed; 

"(4) name of inventorfs), title which was on the specification as filed and filing date; 

m (S) name of inventors), title which was on the specification as filed and reference to an 
attached specification which is both attached to the oath or declaration at the time of execution 
and submitted with the oath or declaration; or 

m (6) name of inventors), title which was on the specification as filed and accompanied by 
a coyer fetter accurately identifying the application for which it was intended by either the 
application number (consisting of the series code and the serial number; e.g.,06/1 23,456), or 
serial number and filing date. Absent any statements) to the contrary, it will be presumed that 
the application Hied in the PTQ is the application which the inventors) executed by signing 
the oath or declaration. 9 

Notice of July 13, 1995 0177 O.G. 60). 

(c) CD was described and claimed in PCT international Application No 

PCT/BW/Q3537 _ filed on ll/Pfi/98 and as 

amended under PCT Article 19 on $f any). 
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SUPPLEMENTAL DECLARATION (37 C.F.R. § 1.67(b)) 



(complete the following where a supplemental declaration is being submitted) 

□ I hereby declare that the subject matter of the 

□ attached amendment 

□ amendment filed on 

was part of my/our invention and was invented before the filing date of the original 
application, above-identified, for such invention. 

ACKNOWLEDGEMENT OF REVIEW OF PAPERS AND DUTY OF CANDOR 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information, which is material to patentability as 
defined in 37, Code of Federal Regulations, § 1 .56, 

(also check the following items, if desired) 

CD and which is material to the examination of this application, namely, information 
where there is a substantial likelihood that a reasonable Examiner would consider 
it important in deciding whether to allow the application to issue as a patent, 
and 

□ in compliance with this duty, there is attached an information disclosure 
statement, in accordance with 37 CFR 1 .98. 

PRIORITY CLAIM (35 U.S.C. §§ 119(aHd)) 

NOTE: The claim to priority need be in no special form and may be made by the attorney or agent if the foreign 
application is referred to in the oath or declaration as required by § 1.63. The claim for priority and 
the certified copy of the foreign application specified in 35 U.S.C. 1 19(b) must be filed in the case of 
an interference (§ 1.630), when necessary to overcome the date of a reference relied upon by the 
examiner, when specifically required by the examiner, and in all other situations, before the patent is 
granted. If the claim for priority or the certified copy of the foreign application is filed after tne date 
the issue fee is paid, it must be accompanied by a petition requesting entry and by the fee set forth 
in § 7.77(5. If the certified copy is not in the English language, a translation need not be filed except 
in the case of interference; or when necessary to overcome the date of a reference relied upon by the 
examiner; or when specifically required by the examiner, in which event an English language translation 
must be Hied together with a statement that the translation of the certified copy is accurate.' 37 C.F.R. 
§ 1.SS(a). 

I hereby claim foreign priority benefits under Title 35, United States Code, §§ H9(aHd) 
of any foreign application(s) for patent or inventor's certificate or of any PCT international 
application® designating at least one country other than the United States of America listed 
below and have also identified below any foreign applications) for patent or inventory's 
certificate or any PCT international application® designating at least one country other than 
the United States of America filed by me on the same subject matter having a filing date 
before that of the application(s) of which priority is claimed. 

(complete (d) or (e)) 

(d) □ no such applications have been filed. 

(e) ED such applications have been filed as follows. 

NOTE; Where item (c) is entered above and the International Application which designated the U.S. itself claimed 
priority check item (e), enter the details below and make the priority claim. 
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PRIOR FORE1GN/PCT APPLICATION(S) FILED WITHIN 12 MONTHS 
(6 MONTHS FOR DESIGN} PRIOR TO THIS APPLICATION 
AND ANY PRIORITY CLAIMS UNDER 35 U.S.C. § 119(«H<*) 



COUNTRY (OR 
INDICATE IF 

rW I) 


APPLICATION NUMBER 


DATE OF FIUNG 
(day, month, year) 


PRIORITY CLAIMED 
UNDER 37 USC 119 








□ YES NO □ 








□ YES NOD 








□ YES NO □ 








□ YES NO □ 




* 




□ YES NO □ 



CLAIM FOR BENEFIT OF PRIOR U.S. PROVISIONAL APPLICATION(S) 

(34 U.S.C § 119(e)) 

I hereby claim the benefit under Title 35, United States Code, § 119(e) of any United 
States provisional application(s) listed below: 



PROVISIONAL APPUCATION NUMBER RUNG DATE 

/ 



/. 



/. 



CLAIM FOR BENEFIT OF EARLIER US/PCT APPLICATION(S) 

UNDER 35 U.S.C. 120 

□ The claim for the benefit of any such applications are set forth in the 
attached ADDED PAGES TO COMBINED DECLARATION AND POWER OF 
ATTORNEY FOR DIVISIONAL, CONTINUATION OR CONTINUATION-IN 
PART (C-l-P) APPLICATION. 
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ALL FOREIGN APPLICATION(S), IF ANY, FILED MORE THAN 12 MONTHS 
(6 MONTHS FOR DESIGN) PRIOR TO THIS U.S. APPLICATION 



Great Britain 


9725430.4 1 December 1997 


PCT/G898/03537 


26 November 1998 



NOTE: If the application filed more than 12 months from the filing date of this application is a PCT filing forming 
the basis for this application entering the United States as (1) the national stage, or (2) a continuation, 
divisional, or continuation-in-part, then also complete ADDED PAGES TO COMBINED DECLARATION 
AND POWER OF ATTORNEY FOR DIVISIONAL, CONTINUATION OR C-/-P APPUCATJON for benefit 
of the prior US. or PCT application® under 35 U.S.C. § 120. 



POWER OF ATTORNEY 

I hereby appoint the following practitioners) to prosecute this application and transact 
all business in the Patent and Trademark Office connected therewith. 

(list name and registration number) 

Clarence A. Green (24,622) 
Mark F. Harrington t '^T^IMS) 

(check the following item, if applicable) 

□ I hereby appoint the practitioners) associated with the Customer Number pro- 
vided below to prosecute this application and to transact all business in the 
Patent and Trademark Office connected therewith. 

□ Attached, as part of this declaration and power of attorney, is the authorization 
of the above-named practitioner® to accept and follow instructions from my 
representative®. 



DIRECT TELEPHONE CALLS TO: 
(Name and telephone number) 

Clarence A. Green 
(2U3) 259-1800 



SEND CORRESPONDENCE TO 

51 Address 
Cbxeace A. Green 
PERMAH iJOKILuLLP. 

Fairfield, CT 06 430 

□ Customer Number 2512 
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DECLARATION 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United 
States Code, and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 



SIGNATURE(S) 



NOTE: Carefully indicate the family (or last) name, as it should appear on the filing receipt and all other 
documents. 



A r\ Full name of sole or first inventor 

(MIDOLEJNmAL^OR NA 



(GIVEN NAME) 

Inventor's signature 
Date -ffiTfgo- 



JQQEiiffiiSE 




FAMILY (OR LAST NAME) 



Z2 



Country of Citizenship United Kingdom 



*3 Z ViUV^c^ " Po;st Offi ce Address Forest-Gate^nirlfr^ 6 NFs 



Residence jofysMtofr^m^^ iinit^ Kingdom 



^ f . ' United Kingdom 




Full name of second joint inventor 
Stuart 



(GIVEN NAME) 

Inventor^ signature 




'gf any 

— 



(MICOt£*!NmAL OR NAME 



MCDONALfl. 

FAMILY (ORLAST NAME) 



l^r^jj^ 

Residence Limes Farmhouse, Upper Lambourn, Hungerford, Berks, RG17 8RG, United Kin 



■SK: i" 



Post Office Address Limes Farmhouse, Unnpr lambourn. Hiinaorf nrri _ R wire. pci7 ape , 
United Kingdom 



jdo^^ 



A 
0 




f\ Full name of third joint inventor, if any 

^ VNJ jnnft^" KWrk FPflNry <: 

- TQlVBH NAME) ^< / (MIDDLE INjTJAL OR NAME) TaMIZY^R LAST NAME) 

Inventqj^ ^nature j^UW^/ 




Date — <(fr|c^ Country of Citizenship iinitoH jrfw^ \ 

Residence 1 Pipers End, Heswall. WirraT L60L£LW, United Kinodom ( ' J\ 
Post Office Address 1 Pipers Fnd. HeswalT WTrrai ifin fiiu im,^ 1 
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(check proper box(es) for any of the following added page(s) 
that form a part of this declaration) 

□ Signature for fourth and subsequent joint inventors. Number of pages added 



□ Signature by administrator(trix), executor{trix) or legal representative for de- 
ceased or incapacitated inventor. Number of pages added 



□ Signature for inventor who refuses to sign or cannot be reached by person 
authorized under 37 CFR 1.47. Number of pages added 



□ Added page for signature by one joint inventor on behalf of deceased inventors) 
where legal representative cannot be appointed in time. (37 CFR 1.47) 



□ Added pages to combined declaration and power of attorney for divisional, 
continuation, or continuation-in-part (C-l-P) application. 

□ Number of pages added 



□ Authorization of practitioners) to accept and follow instructions from representa- 
tive. 



(if no further pages form a part of this Declaration, 
then end this Declaration with this page and check the following Hem) 

B This declaration ends with this page. 
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